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ABSTRACT 



This thesis describes a conceptual design for a software 
tool for automatic detection of synchronization constraint 
deadlock from the formal specification of a distributed 
system. The formal specification language Spec is used to 
define the distributed system. The basic algorithm used is 
introduced using a graphical representation, and its operation 
illustrated via an example. 
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I. 



INTRODUCTION 



A. PURPOSE 

Our goal is to develop a software tool to automatically 
detect the possibility of deadlock in a distributed system 
from the formal specification of that system. The software 
tool will take a formal specification of a distributed system 
as input, and will evaluate whether or not that system, as 
specified, has the potential for deadlock. The tool will 
indicate whether or not the design has potential for deadlock, 
and will produce a graphic depiction of the specification. 
The initial scope of this tool will be limited to 
synchronization constraints on sequences of events that can be 
described using regular expressions. Accesses to such shared 
resources are subject to synchronization constraints that can 
lead to deadlock situations if not designed properly. The 
proposed tool will detect this type of design fault. 

Formal specifications can provide a precise 'black-box' 
description modeling the behavior of a software system. The 
behavior modeled by the formal specification consists of the 
interactions of a software system with other software systems 
or the external world (e.g., operator commands). 

Distributed systems are collections of computers that 
appear as a single machine to its users (Tanenbaum, 1984). In 



1 



a distributed system the interactions modeled by the formal 
specification extend to the use of shared, critical resources 
(such as common data bases). 

B . DEADLOCK 

Informally, a state of deadlock occurs if a process in a 
system, or an entire distributed system, waits for a 
particular event that cannot occur (Deitel, 1990). For 
example, a deadlock occurs if processor A has control of 
resource 1 and needs resource 2 to complete a task, while 
processor B has control of resource 2 and needs resource 1 to 
completes its task and neither processor will yield the 
resource it controls until it completes its assigned task. 
Each processor is waiting for a particular event that cannot 
occur (the availability of an unavailable resource) and is 
unable to proceed. This example describes a two-process 
deadlock. The example illustrates a resource deadlock 
(Chandy, 1983), a deadlock situation that arises because 
processes are permanently waiting for resources held by each 
other . 

A similar situation occurs when a system (or module) 
enters a state from which no transitions to other states are 
possible (i.e., a "trap state"). Such a process is not 
waiting for an event to occur; there are no events specified 
that could allow the module to return to a state from which 
useful work might be performed. This might be caused by error 
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handling policies that did not return the module to an 
operating state (abnormal termination). This module, however, 
may need to generate or pass a message or event to another 
module or system, causing that process to block. This is an 
example of a communications deadlock. A process deadlocked 
because of communications may be able to proceed upon receipt 
of a message from one of several processes from which it may 
be communicating. 

The major difference between resource and communications 
deadlocks is that, in the case of resource deadlock, processes 
cannot proceed until they receive all of the resources that 
they require. In the case of a communications deadlock, the 
receipt of at least one of several potential messages may 
permit the resumption of execution. The communications model 
is considered to be more general than the resource model of 
deadlock. (Chandy, 1983) 

Deadlock and certain associated terms are more formally 
defined in Chapter III. 

C. FORMAL SOFTWARE SPECIFICATION METHODOLOGY 

Formal software specification methods use formal 
languages. A formal language is a set of finite length 
strings of symbols over some alphabet, where the alphabet is 
"a finite set of symbols" (Hopcroft, 1979). With respect to 
computer languages, the alphabet "consists of the permissible 
keywords, variables, and symbols of the language" (Sudkamp, 



3 



1988). In applying these concepts to the specification of 
software systems : 

"Formal methods used in developing computer systems are 
mathematically based techniques for describing system 
properties. Such formal methods provide frameworks within 
which people can specify, develop, and verify systems in 
a systematic, rather than ad hoc, manner. 

A method is formal if it has a sound mathematical basis, 
typically given by a formal specification language. This 
basis provides the means of precisely defining notions 
like consistency and completeness and, more relevantly, 
specification, implementation, and correctness. It 
provides the means of proving that a specification is 
realizable, proving that a system has been implemented 
correctly, and proving properties of a system without 
necessarily running it to determine its behavior. " (Wing, 
1990) 

We can use a formal language consisting of a "clearly 
defined syntax and semantics" to formally specify and describe 
the interfaces of a system or component (Berzins, 1988). 

There are many formal specification methodologies 
available. Some are frequently found in a graphical form, 
such as Petri Nets (Murata, 1989), Communicating Finite State 
Machines (CFSM) (Brand, 1983), and Systems of Communicating 
Machines (Lundy, 1988). Others are normally found in a 
textual form, but can be converted into a graph form for 
deadlock detection analysis. For this project, one of the 
latter, the formal specification language Spec (Berzins and 
Luqi, 1991), (Berzins, 1991), is used. Spec, in particular, 
concisely describes the atomic transactions that can cause the 
occurrence of deadlock. 

The basic units or modules of Spec are definitions, 
functions, types, machines, and instances. A machine is a 
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system with a memory capable of remembering a state. A type 
is a module that defines an abstract data type, consisting of 
a set of values and a set of primitive operations on that 
value set. If a type module has operations that modify the 
value set or change existing instances of the type, it has an 
internal state. 

Chapter II contains a more detailed discussion of formal 
specification methodologies . 

D. SIMPLIFYING ASSUMPTIONS 

Some of the approaches previously used in evaluating 
deadlock potential have been shown to be undecidable in the 
general case. It has not yet been demonstrated whether or not 
this is true for the approaches I am investigating. The 
initial algorithm development discussed in this thesis will be 
restricted to situations that can be proved decidable. To 
ensure this, I will restrict my evaluation to those systems 
whose synchronization constraints can be represented using 
regular expressions . 

E . OVERVIEW 

In this chapter, I have introduced the goals of this 
research and informally discussed the topics of deadlock and 
formal software specification methodologies. In the remainder 
of this thesis, these topics are explained in more detail, and 
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a method for automatic detection for deadlock detection is 
presented . 

Chapter II summarizes the background for my research, and 
includes a review of several formal software specification 
methodologies . I also describe some previous approaches to 
detecting deadlock potential in distributed system, and the 
applicability of existing software tools in this endeavor. 

In Chapter III, I formally define deadlock and certain 
related terms, and summarize the requirements analysis for a 
deadlock detection software tool. I also discuss my rationale 
for choosing Spec as the specific formal specification 
methodology used in the model. This chapter also outlines the 
algorithmic approach I propose for automatic detection of 
deadlock potential, and gives an example of its use. 

Chapter IV summarizes the results of the research and 
describes proposed extensions and additional necessary work. 
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II. BACKGROUND 



A. REVIEW OF FORMAL SPECIFICATION METHODOLOGIES 

There are many different methodologies available for use 
in the formal specification of systems. These methodologies 
may be categorized in many different ways. These 
characteristics include, but are not limited to, whether or 
not a method is graphical in nature, is model based or 
property based, what the underlying mathematical system is, 
intended for sequential and/or concurrent systems, etc. The 
approach I take toward deadlock detection in Chapter III is 
derived from graph theory, but requires a character oriented 
machine readable specification method. In addition, to be 
useful for deadlock detection, the specification methods used 
must be able to specify characteristics of concurrent, 
distributed systems. Separate, sequential systems that do not 
interact with other systems are of no interest for this 
application. Formal methods that can be used for specifying 
large software systems are of particular interest, as this is 
a requirement for real-world applications. 

In the following paragraphs, I summarize several such 
methodologies, commenting on many of their characteristics. 
While the list is clearly not all inclusive, it is 
representative of the many specification formalisms available. 
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1 . 



Petri Nets 



A Petri net is a graphical and mathematical tool 
useful in expressing concurrency and parallelism. 

Petri nets consist of a particular type of directed 
graph, known as a bipartite graph, and an initial state, or 
initial marking . The directed, bipartite graph of a Petri net 
may be weighted, and has two kinds of nodes, places and 
transitions . Arcs in a Petri net start at a place and 
terminate at a transition, or start at a transition and end at 
a place. States are represented by Petri net markings , where 
a marking is a function that assigns a non-negative integer 
value to each place. This assignment is represented by 
tokens, where if the non-negative integer value, k, is 
assigned to place, p, we say that p has k tokens. The formal 
definition of a Petri net is given in Table I (Murata, 1989). 
TABLE I FORMAL DEFINITION OF A PETRI NET 

A Petri net is a 5- tuple, PN- {P, T, F, W, M 0 ) where: 

•P={Pi»P 2 » • • • ,P m ) is a finite set of places, 

T={tf, t ? , , t n ) is a finite set of transitions, 

Fc(PxT) U ( TxP) is a set of arcs ( flow relation) , 

W:F~{ 1,2,3,...} is a weight function, 

Mg : P- {0,1,2, 3, . . .} is the initial marking, 

P n r=0 and P U 7*0. 

A Petri net structure N=(P,T,F,W) without any specific initial 

marking is denoted by N. 

A Petri net with the given initial marking is denoted by (N, Mg) . 



The conventional graphical representation of Petri 
nets use circles for places and bars as transitions. Tokens 
are represented by small dots. A simple Petri net is shown in 
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Figure 2.1. Petri net weights may be represented by either 
multiple arcs of weight one between places and transitions, or 
by labeling arcs with a specific weight. 

In modeling an event or computational step, the 
transition represents the event, and places, conditions. The 




Figure 2.1 Simple Petri Net 

places prior to the transition, or input places, represent 
pre-conditions and the output places following the transition, 
post -condi tions . 

Events occur, and the marking or state changes, when 
a Petri net transition fires. A transition, t, fires after it 
has been enabled, which means that each input place, p it for 
that transition is marked with at least the number of tokens 
indicated by the weight of the arc from p i to t . In a Petri 
net where all arcs have weight one, the firing of a transition 
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removes one token from each input place of the transition and 
adds one token to each output place of the transition. 

In classical Petri nets, the time from when a 
transition, t, is enabled until it fires is indeterminate. 
Similarly, if two different transitions, t x , t 2 , are enabled 
concurrently, the order of firing of t x and t 2 is indeterminate 
(Coolahan, 1983). Transitions can therefore be in conflict if 
the firing of one enabled transition causes the disabling of 
another enabled transition. 

Petri nets can be used in the modeling of finite state 
machines, parallel activities, dataflow computation, 
communication protocols, multiprocessor systems, 
synchronization control of multiprocessor and distributed- 
processing systems and formal languages. Behavioral 
properties including reachability, boundedness, liveness, 
reversibility and fairness have been modeled using Petri nets 
(Murata , 1989 ) . 

Reachability in a Petri net is the determination of 
whether, given an initial marking, M 0 , and a desired marking, 
M n , there exists a sequence of firings that will transform M 0 
to M n . (Kosaraju, 1982) and (Mayr, 1984) have shown that 
Petri net reachability is decidable, though it does require at 
least exponential space and time. Reachability is the 
fundamental, underlying method used in evaluating all of the 
Petri behavioral properties noted above. 
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A Petri net (N, M 0 ) is called k-bounded (or bounded) 
if, for any marking reachable from M 0 , the number of tokens in 
each of the places of the Petri net never exceeds a finite 
number k. If places in Petri nets are used to represent 
buffers, the boundedness property can be used to guarantee the 
lack of the buffers overflowing. 

A Petri net ( N, M 0 ) is considered to be live if it is 
possible to eventually fire any transition of the net from the 
current marking, by progressing through some further firing 
sequence. Thus, a system described by a live Petri net is 
guaranteed to be free of deadlock, no matter what firing 
sequence is chosen. (Murata, 1989) 

Reversibility is a property where the initial marking 
M 0 of a Petri net is reachable from any marking reachable from 

M 0 - 

There are multiple definitions of fairness in Petri 
nets. Two of these are bounded- fairness ( B-fair ) and global 
fairness . A Petri net is B-fair if, for every pair of 
transitions in the net, there is an upper limit (or bound) on 
the number of times that either can fire before the other 
transition can fire. A Petri net is globally (or 
unconditionally) fair if for every firing sequence reachable 
from M 0 , is finite, or every transition in the net appears 
infinitely often in the firing sequence. 

Reachability and liveness analysis using Petri nets 
are further discussed in section B of this chapter. 
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2. Communicating Finite State Machines (CFSM) 



The Communicating Finite State Machine (CFSM) 
methodology was developed for use in modelling communications 
protocols. The CFSM model represents and specifies 

communicating processes as finite state machines. Each pair 
of these processes are connected by a full duplex First-in 
First-out (FIFO) channel (that can be represented by two one- 
way FIFO queues) (Brand, 1983). 

CFSMs are directed labeled graphs with two types of 
edges, sending and receiving . The edges are labeled with the 
name of a message. The label is prepended with a minus sign 
for a sending arc, and a plus sign for a receiving arc. The 
nodes of a CFSM represent its states, and each CFSM has its 
starting state identified by an initial node. If a CFSM node 
has only sending edges, it is referred to as a sending node. 
Similarly, a node with only receiving edges is a receiving 
node. A mixed node is one with both sending and receiving 
edges (Gouda, 1986), (Lundy, 1988). A formal CFSM model for 
an arbitrary number of processes or machines is given in Table 
II (Brand, 1983). 

To illustrate CFSM, we will simplify to using a two 
machine network. Let M and N be two CFSMs sharing the same 
set G of messages. We will call W = (M, N) a network. The 
global state of network W is represented by the four-tuple 
(m, c m , c n/ n) , where m and n are nodes (states) of M and N, 
and c m and c„ represent messages from G being passed from M to 



12 



